-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gstreamer1.0-plugins-nvcompositor: update patches for 1.18 build #864
Conversation
Work in progress. While the build works, tests against the plugin are not working. Signed-off-by: Kurt Kiefer <[email protected]>
Don't worry about the autobuilder failure - the check shouldn't have triggered for a draft PR. Should clear up once you promote the PR to non-draft status. |
FYR, the smoke test:
Fails with the following
Removing the positioning stuff, it fails due to
|
@kekiefer I took a stab at moving this further along, using the sources for the upstream gstreamer compositor plugin as a reference: Hopefully it's readable enough with all the |
@kekiefer I've tracked down the memory management issue and have patches on this branch, if you'd like to give them a try. The nvvidconv plugin also needed fixing; with both of those plugins udpated, your test pipeline ran without error. |
Thanks for getting around to working on this. I'll make the time to review this today. My initial reaction regarding nvvidconv is that a patch to it may not be required. Indeed, nvvidconv has worked fine with 1.18 for me for quite some time. Downstream consumers of nvbuffers do not expect the full buffer size, and they're the only ones that will map these buffers without conversion. Making the size bigger would incur a performance penalty if downstream elements attempt to map the entire buffer (which I think they do), and with large video streams is likely be non-negligible. |
Yeah, I wasn't 100% sure of it, but your test script was generating error messages (but not stopping the pipeline) because of the size mismatches in the memory pool configuration, so I went ahead with it.
Maybe my read of the code was incorrect, but the pool looked like it was used only for dmabuf-backed NvBuffers, and the memory_map function provided in the allocator just retrieves the pointer. So I didn't think it would make a difference. |
You're right about this. Looking back, I ran into this problem when I modified nvvidconv's allocator to subclass The changes to nvvidconv are working with existing code with no detectable regressions. Also I am able to get images out of the nvcompositor so that looks about as sane as any of these plugins are going to get as well. I'll close this PR and you've got my thumbs up to merge the wip branch. |
Work in progress. While the build works, tests against the plugin are not working.